On Wed, Jan 20, 2010 at 1:47 AM, Chia-I Wu <olva...@gmail.com> wrote: > On Wed, Jan 20, 2010 at 3:20 AM, Jakob Bornecrantz <ja...@vmware.com> wrote: >> On 18 jan 2010, at 03.14, Chia-I Wu wrote: >>> On Sun, Jan 17, 2010 at 10:24 AM, Chia-I Wu <olva...@gmail.com> wrote: >>>> I myself would like to see the st_visual and st_api->make_current issues >>>> resolved (listed as issue 1 and 3 in DESIGN file). >>> This is proposed change for issue 1 (st_visual separation) >>> http://cgit.freedesktop.org/~olv/st_api/commit/?h=issue1-proposal&id=604f4e306c81cadab19c5136842712ca9c0f4b8c >>> st_visual is embedded inside both st_context_config and >>> st_framebuffer_config. >> So all of the special variables that you have in the different configs can >> easily derived from what you called available_buffers. >> so: >> ctx_conf::double_buffer = (mask & BACK_RIGHT_MASK) || (mask & >> BACK_LEFT_MASK); >> ctx_conf::stereo = (mask & BACK_RIGHT_MASK) || (mask & BACK_RIGHT_MASK); >> And the for the buffer selection in ES and VG the semantics are very clear: >> desired_render_buffer = (mask & BACK_RIGHT_MASK) ? BACK_RIGHT : FRONT_RIGHT; >> and for GL it pick what it renders to by itself. > There is a subtle difference. Even when a pixmap drawble has a back buffer, > EGL requires the front buffer to be used. Unless we lie in available_buffers, > the st will use the wrong buffer. > > I am fine moving available_buffers to the shared st_visual, and rename it to > probably buffer_mask. It will more or less make st_context_config redundant, > but I think there are attributes or extensions that will require more than > st_visual (e.g. I want a context that supports pre-multiplied alpha?). > > I believe a single st_visual is enough, if we document how a field is used > between st_context and st_framebuffer: field X means st_framebuffer has X' and > it means the user wants X'' to st_context. But, IMHO, it gives more > confusions > than simplifications.
We will burn those bridges when we come to it. I think we should start out small and then work up to a full feature set. I'm also leaning against moving egl specific bits of this api into egl_api.h or something just like with drm_api.h vs dri_api.h. Anyways I think that we should move forwards we actually implementing this, especial the core bits on both egl and another manager like dri. And then take it from there. Cheers Jakob. ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
