On Wed, Jan 20, 2010 at 10:55 AM, Jakob Bornecrantz <wallbra...@gmail.com> wrote: > 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. I am against that too. What I would like to have is a way to express the capabilities of the context/framebuffer _and_ a way to express the user's desire for them. It should be a generic idea.
That said, I think I can base on your patch, and add "render_buffer" to st_visual. How does that sound? > 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. Agree. Many design defects will surface in the early stage of the implementation. On my side, I want to start the work early February. I will start with OpenVG st and egl_g3d st manager first, to verify the design. Since st_api can be implemented parallel to st_public.h, I think a possible path is 1. implement st_api in all state trackers, and then 2. port all st managers to st_api, and then 3. remove st_public.h from state trackers when we are confident with the design. -olv ------------------------------------------------------------------------------ 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
